개발 실력 분해해보기

나는 원래 개발 실력은 여러 가지 능력이 융합되어서 나오는 것이기 때문에 세세하게 뜯어보는 게 별로 중요하다고 생각하지 않았다. 그런데, 최근 팀에서는 채용, 멘토링, 평가 등 다양한 이유로 세밀한 분석이 좀 필요하다고 느껴서 고민을 좀 해봤었고, 이번에 글로 정리를 해보려고 한다.

크게 다음과 같이 분해할 수 있을 것 같다.

1. 이슈에서 할 일 정의하기
2. 설계 및 알고리즘(넓은 의미)
3. 좋은 코드
4. 프로그래밍 언어
5. 기술영역(웹, 모바일, 시스템, 하드웨어, 대용량 데이터 분석 등)
6. 프레임워크

꼭 이 순서대로 일을 해야 한다는 의미는 아니다. 실무에서는 이 과정 전체, 혹은 부분을 여러 번 순환하게 될 수 있고, 또 순환하는 게 바람직하다. 그리고, 의사소통 능력은 모든 단계에서 공통으로 필요하기 때문에 제외했다.

각각의 능력의 중요도는 대략 다음과 같이 본다.

이 여섯 가지를 좀더 구체적으로 살펴보고, 왜 이런 비중으로 보는지를 이야기해 보겠다.

이슈에서 할 일 정의하기#

어떤 이슈가 발생했을 때 그 이슈를 분석해서 어떻게 대응해야 하는지를 식별하는 것이다. 이슈는 고객의 클레임일 수도 있고 외부 사건일 수도 있고 대표의 갑작스러운 생각 변화, 새로운 사실 발견, 비즈니스 전략 변화, 팀원들의 아이디어 제안, 서비스 장애 등 다양한 것일 수 있다. 이런 이슈가 생겼을 때 어떻게 대응할 것인지를 정의하는 게 소프트웨어 개발의 첫 단계다.

보통의 회사들은 이런 능력을 개발자에게 요구하지 않는다. 비즈니스 담당자가 따로 있거나 부서장, 대표 등의 리더가 결정해서 내려온다. 그럼 요구하지도 않는 능력인데 필요한 게 맞나? 나는 그래도 필요하다고 보는데, 기술에 대해서 모르는 사람의 관점에서 보이지 않지만 개발자들은 볼 수 있는 것들이 있기 때문이다. 이 단계는 비즈니스의 성패를 좌우할 수 있는 단계이기 때문에 기술 관점이 들어가야 더 좋은 결정이 될 수 있다. 물론, 처음부터 개발자들과 함께 이 단계를 밟는 회사들은 더 좋은 성과를 낼 거라고 본다.

예를 들어보자. 쇼핑몰인데 배송비를 모두 동일하게 책정한 상태로 시스템이 개발되어 있다고 해보자. 근데, 도서산간 지역 배송이 많이 늘면서 책정한 배송비보다 더 큰 비용이 드는 주문들이 늘어났다. 그래서 비즈니스 담당자들이 배송비용에서 손해를 보지 않기 위해 도서산간 지역에 추가 배송비를 부과하도록 시스템을 수정하자고 한다. 하지만, 배송비는 여러 가지 배송비 무료 조건, 할인 혜택, 쿠폰, 환불 등의 상황에서 복잡하게 계산이 되어야 하는데, 이때 배송비가 주문에 따라 달라지지 않는다는 전제로 개발이 되어 있어서 달라지게 개발하려면 1~2개월 정도의 작업 시간이 필요하다. 그럼 이 배송비 이슈에서 할 일은 어떻게 정의해야 하는가?

나는 일단 손해보는 금액을 계산해봤는데, 대충 월 수십 만원 수준이었다. 월 수십 억 매출을 내는 비즈니스인데 수십 만원 때문에 추가 개발을 한다는 건 누가 봐도 합리적인 결정이 아니었다. 그래서, 나는 손해액이 1백만원 넘어갈 때 다시 논의해보자고 했는데, 1년이 지나도록 넘지 않았다.

또 다른 예를 보자. 온라인 쇼핑몰이지만 오프라인 매장도 있는데, 매장에서 상품을 식별할 때 사이즈나 색상이 뭔지 빠르게 식별하기 위해 상품코드에 사이즈, 색상 등의 부가 정보를 포함시켜달라는 요청이 왔다. 그런데, 상품코드는 자리 수 제한도 있고 과거 데이터와의 매칭 등의 문제가 있어서 쉽게 바꿀 수 없는 것이었고, 색상이나 사이즈를 원문 그대로 담는 게 아니라 축약한 기호로 담아야 했기 때문에 다 외워야만 식별이 가능하다는 문제도 있었다. 그래서 나는 실제로 그 상품코드가 매장에서 어떻게 식별되는지를 알아봤는데, 알고보니 라벨 프린터로 프린트해서 상품에 붙여두는 거였고, 그 라벨 프린터의 출력은 커스터마이즈가 가능했다. 그래서, 그냥 배송관리 시스템에 보낼 때 프린트할 라벨 텍스트도 추가로 보내는 방식을 제안했고, 덕분에 상품코드 체계의 복잡성을 높이지도 않고 개발 분량도 적지만 오히려 현장 직원에게는 더 편리한 방안이 나왔다.

오히려 일을 늘리는 판단을 하는 경우도 있다. 비즈니스 지표에서 DAU와 MAU는 매우 중요한 역할을 하는데, 이걸 처음에는 Google Analytics만으로 측정했다. 그런데, GA의 데이터가 때때로 집계가 늦어져서 며칠 후에 나오는 경우가 생기니 그날그날 전환율이 정확하지 않은 문제가 있었다. 그래서 GA의 집계가 아니라 빅쿼리와 연동해서 raw data로 직접 집계하는 것도 시도했는데, 이건 이거대로 늦어지는 경우가 생겼다. GA처럼 글로벌하게 널리 쓰이는 제품을 믿지 말아야 할까? 그냥 며칠 기다리면 다시 정확한 수치로 집계가 되는데 굳이 매일매일 정확한 데이터를 봐야 할까?

하지만 난 DAU, MAU의 중요성이 너무 크다고 생각했고, 그래서 그냥 자체 집계를 해서 보완하기로 했다. 하지만 그동안 GA로 집계를 해왔기 때문에 지표의 일관성이 필요했다. 그래서, GA에서 세션을 판단하는 기준 등을 상세히 찾아보고 가능한 한 비슷한 숫자가 나오게 구현한 다음, 며칠 동안 데이터를 지켜보면서 충분히 유사한 값이 나오게 되었을 때 지표에서 자체 집계를 사용하기로 했다.

그러나, 자체 집계 한다고 오픈소스 analytics 엔진을 쓴다든지, 이런 집계에 적합한 엔진을 별도로 쓴다든지 하면 또 개발 비용이 커진다. 그래서 내가 선택한 방법은 그냥 RDBMS로 쓰던 postgresql에 테이블 만들고 이벤트를 다 밀어넣는 것이었다. 이벤트 수가 너무 많아지면 감당이 될까 하는 걱정이 있을 수 있지만, postgresql의 한계는 매우 크다. 그래서 코드 분량도 수십 라인 정도에서 커버가 되었고, 고객 데이터와 같은 DB에 있었기 때문에 이벤트와 엮어서 다른 분석도 쉽게 할 수 있다는 부수적인 장점도 얻을 수 있었다.

이처럼 이슈가 나오는 대로 무조건 해결하는 게 아니라, 때로는 무시하고 넘어가야 하고, 때로는 기술적으로 가벼운 방법을 찾고, 때로는 더 개발 분량을 늘려서라도 제대로 해결하는 방법을 찾아야 한다. 비즈니스 파트에서는 개발 비용에 대한 감이 없기 때문에 일단 해결하는 것만 생각하기 쉬우므로 개발자가 개발 비용까지 감안해서 더 좋은 결정을 내릴 수 있도록 의견을 줘야 한다.

설계하고 알고리즘 짜기#

앞 부분은 비즈니스 관점이 많이 섞인다면, 여기서부터는 순수(?) 개발 실력이라고 부를 수 있는 부분이다. 참고로 여기서 말하는 알고리즘은 퀵소트 그런 게 아니라, 사전적인 정의의 알고리즘, “특정한 문제를 해결하거나 계산을 하기 위한 수학적으로 엄밀한 명령 순서의 유한한 집합”이다.

숙련된 시니어 개발자들은 보통의 업무에서 대개 할 일과 코드 사이에 있는 작업들이 머리 속에서 즉각적으로 일어나는 경우가 많아서 이 단계가 존재한다는 것을 인지하기 어려울 수 있다. 하지만, 주니어들은 대개 이 단계에서 어려움을 겪는다. 이 단계 안에도 여러 종류의 일이 있기 때문에 한 번 더 나눠보겠다.

아키텍처 설계#

예를 들어 보자. 내가 개발하고 서비스 중인 웹사이트에 고객 상담 채팅 기능을 추가하자는 이야기가 나왔다. 나도 그 기능의 필요성에 동의한다. 그럼 이제 어떻게 설계할 것인가?

제일 먼저 고려할 방법은 날로 먹을 방법이 없는지를 찾는 것이다. 예를 들면 채널톡 같은 외부 서비스를 대충 붙일 수 있다. 근데, 우리는 고객 상담 데이터를 깊이 있게 분석하고 AI에게 학습도 시켜서 여러 가지 용도로 쓰고 싶은데, 채널톡 API는 그런 작업까지 하기에는 좀 부족하다고 봤다. 그럼 이제 자체 구현할 방법을 찾아야 한다.

우선, 채팅에는 비동기 서버가 필요하다. 만약 node.js로 서버를 구축했다면 간단하게 웹소켓으로 채팅을 구현할 수 있다. 근데 우리는 asyncio를 사용하지 않고 그냥 gunicorn sync 서버를 사용 중이다. 여기서 선택지가 여러 가지 나온다.

asyncio에는 여러 가지 비효율이 있기 때문에 이제 와서 asyncio로 전환하기는 싫다. 그렇다면 기존 코드의 큰 변화 없이 갈 수 있는 방법으로 gevent가 있다. gunicorn worker를 gevent로 바꾸고 채팅 웹소켓을 연결할 handler를 gevent로 작성해주면 된다. 채팅 기능에 대한 코드만 작성하면 되고 서버만 바꾸면 되니까 변경 비용이 크지 않아 보인다.

하지만, gunicorn worker를 gevent로 바꾸면 그동안 성능 최적화를 해둔 기준이 바뀌게 된다. gevent는 sync worker와 성능 특성도 다르고 재시작할 때도 웹소켓을 기다리는 등의 부작용이 있다. 그래서 코드 변화는 적지만 서버 운영에서 약간 작업이 늘어난다.

이보다 더 단순한 방법도 있을까? rabbitmq 같은 message queue를 사용하는 방법이 있다. 파이썬 코드에서는 채팅 메시지를 클라이언트에 보낼 때 그냥 message queue에 보내고, 웹에서는 message queue에 STOMP 같은 걸로 웹소켓을 연결해서 처리할 수 있다. 웹 쪽 코드는 어차피 웹소켓을 받아서 처리하는 거라서 동일하고 서버 코드도 gevent에서 소켓에 쏘는 거랑 비슷하다. gunicorn 서버를 유지하는 대신 message queue 서버를 세팅해야 한다. 다만 message queue는 이미 손쉽게 클러스터링할 수 있는 솔루션이 많이 나와 있고 성능 이슈가 단순하기 때문에 운영 부담이 적고, gunicorn의 성능 이슈는 기존의 sync worker만 쓰는 것과 동일하다.

두 방법 모두 나쁘지 않은 방법으로 보인다. 고민 끝에 파이썬은 동기 모드로만 유지하는 것이 부담이 적다고 판단해서 메시지 큐를 도입하기로 한다.

이렇게 고민하고 기술을 결정하는 과정이 개발의 첫 단계가 된다.

데이터 모델 설계#

큰 아키텍처가 결정되면 그 다음은 이 기능에 필요한 데이터 모델을 설계하게 된다. 데이터를 어떻게 DB에 담을지, 여러 전송 계층에서 어떤 포맷으로 전송할지 등을 정의하는 것이다. 먼저 채팅에 필요한 메시지를 그대로 DB에 담는다면 대충 다음과 같이 설계할 수 있다.

@dataclass
class Message:
    channel: Channel
    sender: User
    content: str
    sent: date

근데 만약에 사용자가 첨부파일을 올리도록 해야 한다면 어떻게 해야 할까? Message에 직접 file을 담을 수도 있고, 한 메시지에 여러 개의 첨부파일을 허용한다면 1:N 관계가 필요하다. 후자로 간주하면 다음과 같은 모델이 추가로 필요하다.

@dataclass
class Attachment:
    message: Message
    filename: str
    file: BinaryIO

코딩해야 하는 요소 정의하기#

데이터 모델까지 나오면 이제 무슨 코드를 작성해야 하는지 리스트업이 필요하다. 대충 다음과 같은 것들을 만들면 될 것 같다.

• 채팅 상담 요청 버튼
• 버튼 클릭하면 채팅 UI 띄우기
  • 채팅 메시지 표현 - 보낸 사람, 메시지, 날짜 표시
  • 채팅 입력창
• 과거 채팅 기록이 있으면 미리 로딩
  • 서버에서 message query해서 응답하는 API
  • API 호출해서 reactive data에 담기
• 채팅 입력하면 API 호출
  • 채팅 입력 API
    • DB에 저장
    • 채널명으로 라우팅하고 메시지 내용을 담아서 MQ에 푸시
• 채팅 UI에서 웹소켓 연결
  • 메시지 수신하면 reactive data에 담는 코드

이 리스트가 아주 정교할 필요는 없다. 머리 속에서 한 번에 되는 것들은 굳이 리스트업하지 않아도 된다. 실제 코딩하면서 조금씩 리스트를 수정해 나가게 된다.

알고리즘 짜기#

할 일 리스트업까지 다 되었다면 이제 코딩으로 들어간다. 코딩 단계에서도 어떻게 코딩할지 순서를 잡는 일이 필요하다. 코딩에 좀 숙련이 되었다면 이 단계의 많은 부분은 무의식적으로 하게 되지만, 초심자는 의식적으로 해야 하는 경우가 있고, 문제의 크기에 따라 숙련자도 의식적으로 해야 하는 것들이 있다.

채팅 구현에서 좀 어려운 부분은 스크롤이다. 새로운 메시지를 받으면 맨 아래로 스크롤을 해줘야 하는데, 또 위로 올려서 메시지 기록을 보는 중에는 스크롤하면 불편해서 보통 새 메시지가 왔다는 팝업을 띄운다. 이런 동작을 바로 코드로 작성할 수도 있겠지만, 미리 다음처럼 알고리즘을 짤 수도 있을 것이다.

1. 새 메시지를 받는 핸들러에서
   1. 현재 스크롤 위치를 가져와서 현재 바닥에 있는지를 식별한다.
   2. reactive data에 넣는다. vue라면 messages 배열에 push, react라면 setMessages 같은 식
   3. 현재 위치가 바닥이었으면 아래로 더 스크롤한다.
   4. 바닥이 아니었으면 팝업을 띄우는 플래그를 세팅한다.
2. 팝업에는 클릭하면 바닥으로 스크롤하는 기능을 넣는다.

이런 과정이 정리되면 코드로 옮기면 된다.

다양한 레벨을 오가면서 설계하기#

위에서 설계 및 알고리즘 단계를 세 가지 정도로 나누었고, 코딩을 포함하면 네 가지가 되는데, 주의해야 할 것은 이 단계가 가역적이어야 한다는 것이다. 알고리즘을 짜다보면 모델에서 부족한 점이 발견되기도 하고, 아키텍처 변경이 필요해지기도 한다. 코드를 작성할 때도 선택한 아키텍처로 인해 코드의 복잡도가 특정 수준 이하로 안 내려가서 다시 첫 단계로 돌아가는 경우도 있다. 소프트웨어 뿐 아니라 다른 분야에서도 전문가들은 대개 다양한 추상 레벨을 넘나들면서 작업을 한다고 한다. 그리고, 이 단계도 편의상 세 단계로 나눈 것이지 더 다양한 기준으로 나눌 수도 있다. 물론 가역적이어야 하는 단계의 범위는 이것보다도 앞 단계, 이슈 정의하는 단계도 포함된다.

회사에서 일을 처음 해본 주니어들은 세부 코딩을 하다가 초기 단계의 설계를 수정해야 하는 일을 만나면 “처음부터 설계를 잘 했어야지 이 회사는 주먹구구식으로 일하는구만” 같은 반응을 많이 보인다. 하지만, 처음부터 설계를 잘하는 사람은 없다. 제프 딘도 불가능한 일이다. XP에서도 BigDesignUpFront 대신 LittleDesignUpFront를 하자고 이야기한다. 앞 단계에서 너무 많은 시간을 보내기보다 빠르게 설계하고 코딩하고 결과물을 만져보는 과정에서 계속 설계를 수정해가는 것이 좋다.

코드 품질#

기본적으로 주어진 미션을 달성할 수 있을 만큼의 설계 능력을 갖추었다면 그 다음으로 생산성에 영향을 많이 미치는 것은 좋은 코드를 만들어 내는 능력이다. 코드 품질은 첫 개발 때는 상관 없고 유지보수 때부터 영향을 미친다는 이야기가 많이 통용되는데, 나는 그렇게 생각하지 않는다. 프로젝트의 크기가 프로그래머의 머리 속 컨텍스트의 크기를 넘어서기 시작할 때부터 낮은 코드 품질은 생산성을 깎아먹기 시작한다. 이 이야기는 이미 상세하게 적어둔 글이 있기 때문에 그 글, Simple Design에 맡기고 넘어간다.

프로그래밍 언어#

설계 능력과 코드 품질이 충분히 좋다면 대개 어떤 프로그래밍 언어로 코딩을 해도 높은 생산성이 나온다. 위의 설계 예시를 보고 나면 프로그래밍 언어 잘 몰라도 채팅 구현할 수 있을 것 같은 느낌이 들지 않는가? 만약 여러 언어를 다루는 프로그래머가 한 언어만 다룬 프로그래머보다 높은 생산성을 낸다면 그것은 앞에서 이야기한 설계 및 알고리즘 능력들이 더 좋은 것이다.

그렇지만 여기서 만족할 수 없다. 각 프로그래밍 언어에 맞춰서 생산성을 극대화할 필요가 있다. 프로그래밍 언어는 설계 단계부터 코드 품질 문제와도 엮이고 실제 코드에도 큰 영향을 미친다. 특히 대부분의 개발자는 중저급 언어보다는 고급언어로 애플리케이션 개발을 할 텐데, 고급언어들은 코드 품질을 높이기 위한 문법들이 다양하게 제공되는데, 이런 것들을 얼마나 잘 다루느냐가 코드 품질에 큰 영향을 미친다.

실무에서 애플리케이션을 개발할 때는 대개 특정 프레임워크를 쓰게 되지만, 그럴 때도 프레임워크에 대한 이해도보다 언어에 대한 이해도가 더 중요하다. 당장의 구현은 프레임워크의 기능들을 중심으로 하게 되겠지만 그런 기능들은 결국 해당 언어의 모듈, 패키지, 클래스, 메서드/함수, 변수, 그 외 자료구조에 매핑되기 때문에 해당 언어를 잘 알아야 응용도 가능하고 리팩토링도 잘할 수 있다.

또한 프레임워크 자체가 언어의 특성을 깊이 활용하는 경우가 많다. 예를 들어 React는 자바스크립트의 클로저 위에 쌓아올려져 있다. 파이썬에서 커맨드라인 툴을 만드는 프레임워크인 typer는 파이썬의 함수 하나를 커맨드 하나에 매핑하고 커맨드의 인자도 함수의 인자에 매핑한다. django의 queryset은 generator를 잘 모르고 쓰면 전체 row를 메모리에 담게 된다든지 하는 사고를 칠 수 있다. Android SDK는 자바의 OOP와 익명 클래스를 깊이 활용한다. Ruby on Rails는 초기에 monkey patching이 매우 쉽다는 특성을 적극적으로 활용해서 코드를 짧게 만들고 human readable하게 만들 수 있었다.

이런 개념들을 잘 이해하고 프로그래밍 언어에 숙련도가 높아지면 그 언어에서 새로운 프레임워크를 만나도 초기 학습 시간을 거의 쓰지 않고 매뉴얼 봐가면서 실무에 적용할 수 있게 된다. 그래서 나는 프레임워크보다 프로그래밍 언어를 잘하는 게 두 배 정도 중요하다고 본다.

기술영역#

여기서 말하는 기술 영역은 웹, 모바일 앱, 시스템 프로그래밍 등의 기술 분야를 말하는 것이다. 이런 영역에 대한 이해가 부족하면 여러 가지 문제를 일으키게 된다. 안다고 해서 생산성을 올려준다기보다는, 모르면 삽질을 많이 하게 되고 중대 결함을 일으킬 수 있다. 요즘은 특히 프레임워크가 이런 부분을 많이 커버해주다보니 이런 지식을 몰라도 개발할 수 있는 경우가 많은데, 또 프레임워크가 모든 영역을 문제 없이 감싸주는 것은 아니기 때문에 그런 구멍에서 사고가 나는 경우가 많다.

예를 들어 웹 개발을 하는데 서버와 브라우저가 어떻게 정보를 주고 받는지 모르고 그냥 next.js 같은 프레임워크만 쓸 줄 아는 개발자들이 흔히 저지르는 실수가 있다. 개발하면서 로그를 찍어봐야 하는데 SSR이 호출되는 코드에서 로그를 찍어놓고 웹 브라우저에서 본다든지, useEffect 안에서 실행되는 코드인데 개발서버 콘솔에서 로그를 보고 있다든지 하는 것이다. 어떤 코드가 어디서 실행되고 어떻게 데이터를 주고 받는지 알면 간단한 문제인데, 요즘은 그런 지식을 쌓을 기회가 부족한 것 같다. 프레임워크들이 너무 편리해져서 생긴 역설인지도 모르겠다.

모바일 앱을 개발할 때도 iOS와 안드로이드의 특성, 각 플랫폼의 정책, 보안사항, 백그라운드 작업의 특성 등을 잘 이해하지 못하면 아예 안되는 기능을 만들려고 기획하는 경우도 종종 있다. 또 리얼타임 OS에서 동작해야 하는 소프트웨어를 만드는데 성능 문제를 간과한다든지, 대용량 데이터 처리 엔진을 만드는데 메모리가 터지게 만든다든지 하는 경우도 흔하다.

이런 각 영역의 기술적 특성들을 잘 알고 있고, 사용하는 프로그래밍 언어에 숙련이 되어 있다면 대개 프레임워크를 보기만 해도 쉽게 이해하고 사용할 수 있게 된다. 그리고, 그런 프레임워크를 만드는 사람들이 바로 이런 실력이 높은 사람들이다.

프레임워크#

이 섹션은 아마도 별다른 설명이 필요 없을 것이다. 사용자에게 닿기 위한 마지막 관문이므로 프레임워크도 충분히 잘 다룰 수 있어야 한다. 근데 사실 이 구분에서 내가 하고 싶은 이야기는 이 영역의 중요성이 과대평가되고 있다는 것이다. 내가 대충 5% 정도로 잡긴 했지만, 어쨋든 이보다 중요한 능력이 많은데 다들 마치 프레임워크를 다루는 능력이 개발 실력의 90% 쯤 되는 것처럼 굴고 있다.

요즘 신입 개발자들보면 프레임워크는 꽤 잘 알고 입사한다. 근데, 정작 실무를 시켜보면 어떻게 개발해야 할지 감을 못 잡고 헤매는 경우가 많다. 분명히 프레임워크에서 다 배운 기능을 조합하면 쉽게 개발할 수 있는 기능인데, 뭘 가져다 써야 할지 헤맨다. 뭐 신입이니까 당연하긴 한데, 이런 상황에서 자기 실력을 올리고 싶으면 설계 능력을 포함한 상위 단계의 능력들을 더 계발해야 하지 않을까? 하지만, 그냥 프레임워크를 더 공부하거나, 심지어 이직 가능성을 올리고자 다른 프레임워크를 추가로 공부하는 사람들이 더 많은 것 같다.

물론 이건 세상을 이런 식으로 이끌고 있는 시니어 개발자들의 책임이다. 하지만, 시니어들이 잘못된 방향으로 이끈다고 해서 그냥 따라가지 말고 개발 실력이라는 게 뭔지 좀더 스스로 생각해보면 좋겠다.

개발 실력을 분해해서 어디다 쓸까?#

지금까지 개발 실력을 분해해봤는데, 논란 거리가 많지만 일단 이런 분해에 동의한다고 치고, 그럼 이 분해 결과를 어떻게 활용할 것인가?

내 생각에 이런 분석이 제일 중요한 곳은 채용이다. 모든 개발팀은 실력 있는 개발자를 뽑고 싶어하는데, 그렇다면 그 실력이 뭔지 잘 정의하는 게 중요하지 않겠는가. 그 실력을 스프링 3년 경력, 리액트 4년 경력 이런 걸로 정의하고 싶은가? 특히 기술 면접 단계에서 이런 요소들을 평가할 수 있어야 한다. 하지만, 이 요소들도 모두 평가하기에는 시간이 부족할 것이므로 상황에 따라 적절히 취사선택을 할 필요가 있다. 만약에 아키텍처부터 새로 잡아야 하는 상황이면 아키텍처 설계 능력을 평가할 수 있어야 한다. 근데 이미 아키텍처 설계가 잘 되어 있다면 그 다음 모델 설계 단위부터 잘하는지를 평가할 수 있다. 모델 설계 능력을 안 봐도 되는 경우는 없을 거라고 본다. 그리고 알고리즘(넓은 의미의)을 다루는 능력도 중요하다. 데이터를 어디에 담고, 그 데이터로 어떻게 for loop를 돌려야 하는지 정도는 할 수 있어야 한다. 그래서 나는 주로 이 두 가지에 집중해서 기술 면접을 봤다.

그 다음은 팀원들의 역량 성장이다. 팀원마다 부족한 부분을 찾고 그 부분을 끌어올릴 수 있도록 가이드를 주고, 경험할 수 있는 기회를 줘야 한다. 아키텍처 설계 능력을 키워야 하는데 팀장이 다 설계해버리면 팀원은 어떻게 성장하겠는가. 계속 삽질하더라도 스스로 해볼 수 있는 기회를 줘야 한다. 그냥 역량평가만 한다면 굳이 개발 실력을 분해해서 평가할 필요가 없을 수 있지만, 팀이 같이 성장해나가고자 한다면 부분부분 짚어줄 필요가 있다.

물론 타인 뿐 아니라 자신의 성장에도 활용할 수 있다. 개발자는 다른 분야에 비해 코치 없이도 스스로 성장하기 쉬운 분야다. 비단 이 글 뿐 아니라 여러 가지 기준으로 자기 실력을 스스로 평가해보고 발전할 길을 찾아가보면 도움이 될 것이다.